Universal Plug and Play (UPnP) is an industry-wide ongoing development for an open network architecture that is designed to enable simple, ad hoc communication among distributed devices and software applications from multiple vendors. UPnP leverages Internet technology and extends it for use in non-supervised home networks. UPnP aims at controlling home appliances, including home automation, audio/video, printers, smart phones, etc. UPnP distinguishes between Control Points (CPs) and controlled devices (CDs). CPs comprise, e.g., browsers running on PCs, wireless pads, etc., that enable a user to access the functionality provided by controlled devices.
UPnP defines protocols for discovery and control of devices by CPs. UPnP does not define a streaming mechanism for use by AudioVideo devices. Some of the discovery and control protocols are part of the UPnP specification while others are separately standardized by the IETF (Internet Engineering Task Force).
Interaction between CPs and devices is based on the Internet protocol (IP). However, UPnP allows non-IP devices to be proxied by a software component running on IP-compliant devices. Such a component, called Controlled Device (CD) proxy, is responsible for translation and forwarding of UPnP interactions to the proxied device.
A UPnP device has a hierarchy of sub-devices with at the lowest level services. Both devices and services have standardized types. A device type determines the sub-devices or services that it is allowed to contain. A service type defines actions and state variables that a service is allowed to contain. State variables model the state of the device, actions can be invoked by a CP in order to change that state. The description of the state variables and the actions is called the SCP (Service Control Protocol). A UPnP device provides a description of itself in the form of an XML document. This document contains, among other things, the service types that it supports. Optionally, a device may have a presentation server for direct UI control by a CP.
UPnP relies currently on AutoIP, which provides a means for an IP device to get a unique address in the absence of a DHCP server. UPnP defines a discovery protocol, based on UDP multicast, called SSDP (Simple Service Discovery Protocol). SSDP is based on devices periodically multicasting announcements of the services that they provide. An announcement contains a URL to which service actions are to be sent: the control server. In addition to that, CPs may query the UPnP network for particular device or services types or instances.
UPnP relies on GENA (Generic Event Notification Architecture) to define a state variable subscription and change notification mechanism based on TCP.
After a CP has detected a service it wants to use (via SSDP), it controls the service by sending SCP actions to the control server URL or querying for state variables. Actions are sent using HTTP POST messages. The body of such a message is defined by the SOAP (Simple Object Access Protocol) standard. SOAP defines a remote procedure call mechanism based on XML.
The UPnP AV (audio/video) specification relates to interaction between UPnP AV devices, e.g., TV sets, video recorders, DVD players, settop boxes (STBs), PCs, etc., and the associated CPs. The UPnP AV specification defines a MediaServer device and MediaRenderer device and their services. A MediaServer (MS) on the network stores AV content and exposes it to other devices on the network. Content items are stored in a hierarchical view, similar to file folders in an electronic filing system on a PC, for example. A MediaRenderer (MR) on the network plays back the AV content stored at the MSs.
As to selecting and playing back a content item (still picture, video, audio, etc.) on a UPnP AV network, the MS, MR and CP typically interact with one another as follows. The user uses the UPnP AV CP to browse content on the MS. Here, every item is shown in its organizational context, having a relationship with other items or clusters of items, not unlike a directory structure. The CP can determine the logical parent, siblings, etc., of a particular item and retrieve information about these. Once the user has selected a particular item to be rendered on the MR, the CP selects a suitable resource representing the item in a particular format and forwards to the MR a pointer, referred to as a “Uniform Resource Identifier”, or URI, and pointing to the resource. A URI is a type of formatted identifier that encapsulates the name of an (Internet) object, and labels it with an identification of the name space, thus producing a member of the universal set of names in registered name spaces and of addresses referring to registered protocols or name spaces. As a result of the way UPnP AV has been defined, this URI has lost the logical context that exists in the MS structure. That is, it is not possible anymore to determine parent, siblings etc. The MR uses this URI as supplied in order to render the item.
A ConnectionManager (CM) in UPnP is a service-type that enables modeling of streaming capabilities of AV devices, and binding of those capabilities between devices. Each device that is able to send or receive a stream according to the UPnP AV device model has one instance of the CM service. This service provides a mechanism for CPs to: perform capability matching between source/server devices and sink/renderer devices; find information about currently ongoing transfers in the network; and setup and teardown connections between devices. The CM service properly abstracts different kinds of streaming mechanisms, such as HTTP-based streaming, RTSP/RTP-based and 1394-based streaming. The CM enables CPs to abstract from physical media interconnect technology when making connections.
The AV Transport (AVT) service in UPnP provides actions that allow a CP to control the flow of the content. This includes operations such as Play, Stop, Pause, Seek, etc. A CP uses the AVT to identify the content that is to be played. This is accomplished by forwarding the URI, obtained from the CDS for the desired content and the selected protocol and format. Dependent on the protocol for transfer of the content, either the MS or the MR may provide an instance of the AVT service. If the selected protocol is a “pull” model (e.g., HTTP GET), then the MR is required to provide an instance of AVT to control the flow of the content (e.g., play, pause, seek). If the selected protocol is a “push” model, then the server must provide an instance of AVT.
While the UPnP Architecture describes, and prescribes, many aspects of devices that are required for a certain level of interoperability, it does not describe anything related to streaming between devices. The purpose of the CM service is to make these aspects of devices explicit, so that CPs are able to make intelligent choices, present intelligent user interfaces, and initiate (and terminate) streams between controlled devices via UPnP actions. While the actual stream of the data packets occurs outside of a UPnP-defined protocol such as SOAP, SOAP is used to initiate (and terminate) the stream.
The CM service defines the notion of “ProtocolInfo” as information needed by a CP in order to determine compatibility between the streaming mechanisms of two UPnP controlled devices. For example, it contains the transport protocols supported by a device, for input or output, as well as other information such as the content formats (encodings) that can be sent, or received, via the transport protocols. Note that UPnP prescribes the use of HTTP for controlling devices via SOAP, but that UPnP does not require HTTP to be used for all kinds (Audio and Video) streaming in a UPnP network. In UPNP, ProtocolInfo specifies the network and the protocol to be used for rendering a content item
The term “ProtocolInfo” is used to describe a string formatted as:
<protocol>‘:’<network>‘:’<contentFormat>‘:’<additionalInfo>
wherein each of the four elements may be a ‘*’, or wildcard. CPs can match protocol info by string comparison operations on the <protocol>, <network> and <contentFormat> elements, taking into account the ‘*” wildcard, which ‘matches’ with anything. The <additionalInfo> part does not need to match between MS and MR. Its purpose is to convey any additional information needed to set up the out of band stream (e.g., 1394 addresses).
A CP and an MS can be physically combined within a single device, referred to as a “combo” device. Examples of an MS are, a video recorder, a DVD player, a CD player, a digital camera or camcorder, a TV tuner, a settop box, a PC. Examples of an MR are a TV display monitor, speakers, a PC, an MP3 player, etc. Each device that is able to send or receive a stream of data according to the UPnP AV device model comprises one instance of a Connection Manager service (CM). A CM provides a mechanism for CPs to perform capability matching between MS devices and MR devices; to find information about transfers on the network currently ongoing; and to initiate and terminate connections between devices. The CM thus enables CPs to abstract from physical media interconnect technology when making connections.